SVCMON UDCs

The table below lists the SVCMON-specific system UDCs. These UDCs are not associated with info items. For a list of SVCMON UDCs that are associated with info items see Info Items.

Note: All SVCMON UDCs begin with the letters SVM.

UDC UDC Description Description Point Type Service Type(s) Data Scope

SVMSTPT*

Site Ping Time

The average time (in milliseconds) it takes to ping all services for the site specified in the point’s Facility ID field.

Format for Facility ID is: SITE_SERVICE.

Analog Input

Any Site

Site

SVMSTST

Site Status

Returns the status (health) of the site specified in the point’s Facility ID field. Worst case is returned.

Format for Facility ID is: SITE_SERVICE.

String Input

Any Site

Site

SVMSTSTDEF

Site Status (Defined)

The number of defined services for a site.

Analog Input

Any Site

Site

SVMSTSTFAL

Site Status (Failed)

The number of failed services for a site.

Analog Input

Any Site

Site

SVMSTSTOK

Site Status (OK)

The number of OK services for a site.

Analog Input

Any Site

Site

SVMSTSTOOS

Site Status (OOS)

The number of Out of Service services for a site.

Analog Input

Any Site

Site

SVMSTTPT

Site Ping Time (Total)

The sum of all pings for all OK services for a site in milliseconds.

Analog Input

Any Site

Site

SVMSVPT*

Service Ping Time

The time (in milliseconds) it takes to ping a service specified in the point’s Facility ID field.

Format for Facility ID is: SERVICE.

Analog Input

All

Single Service

SVMSVST

Service Status

Returns the status (health) of the service specified in the point’s Facility ID field. Format for Facility ID is: SERVICE.

The values for SVMSVST UDC are described in the following table:

Value Description
0, OK The CygNet service is running
-9, OOS The CygNet service is not in service
-10, FAILED The CygNet service has failed
-11, NOT FOUND Service name not in ARS
-12, ERROR Unable to contact a CygNet directory service

See the DCL Function Return Codes for more information.

String Input

All

Single Service

* CygNet sends 12 bytes in a ping request to more accurately reveal actual end-to-end messaging performance between resources on the network. This may result in higher reply times than the commonly used Ping command.